The present invention generally relates to delivering an audio-visual content to a client device, an interconnecting device interconnecting a first network to a second network, the client device being connected to the second network, an equipment adapted to provide the audio-visual content being connected to the first network.
In the past, most video live streaming technologies relied on streaming protocols such as RTP (“Real-time Transport Protocol”, as defined in the normative document RFC 3550) or RTSP (“Real-Time Streaming Protocol”, as defined in the normative document RFC 2326). Today's live streaming technologies are almost exclusively based on the HTTP (“HyperText Transfer Protocol”, as defined in the normative document RFC 2616) protocol and designed to work efficiently over large and distributed HTTP networks such as the Internet.
Adaptive Bitrate Streaming (ABS) is one popular HTTP streaming technique used in streaming contents over computer networks and HLS (“HTTP Live Streaming”), which is a live streaming communications protocol based on HTTP and developed by Apple Inc., is one particular implementation. HLS works by breaking the overall AV (“Audio-Video”) stream into a sequence of small HTTP-based file downloads, each containing one chunk of an overall potentially unbounded transport stream. The AV content is thus divided into chunks, wherein a chunk is a portion of the AV content, whatever is the actual resolution, which corresponds to a time segment of the AV content. As the AV stream is played, a client device decoding the AV content may select from a quantity of different alternate versions containing the same material encoded at various respective bit rates, allowing the streaming session to adapt to available network resources and/or available processing resources of the client device. At the start of the streaming session, the client device downloads a playlist in the form of a text file with an M3U, or m3u8, file extension. This text file contains the metadata for the various streams which are available for the concerned AV content. The various streams that correspond to the respective bit rates are also referred to as layers.
A similar ABS approach is implemented by Smooth Streaming, which is a feature of Internet Information Services (IIS) Media Services, an integrated HTTP-based media delivery platform provided by Microsoft Corp. Contrary to HLS wherein the AV stream is truncated in plural files containing chunks complemented with playlist files, Smooth Streaming relies on a single AV file truncated into pieces, each piece of file containing a descriptor indicating the concerned layer and a reference time in the AV content. Protocol basis and benefits are however equivalent.
One may similarly consider Adobe Systems' HTTP Dynamic Streaming (HDS) and Dynamic Adaptive Streaming over HTTP, a multimedia streaming technology developed by the Moving Picture Experts Group, and referred to as MPEG DASH, which is related to HDS, HLS and Smooth Streaming.
HTTP-based streaming technologies are very convenient, as HTTP allows going through firewalls and guarantees data integrity by relying on TCP (“Transmission Control Protocol”, as defined by the normative document RFC 793). However, the unicast nature of HTTP in the context of ABS is creating huge scalability issues for CDN (“Content Delivery Network”) operators that prevent them from adopting ABS-based mechanisms for live streaming. Indeed, HTTP-based streaming technologies can be unsustainable in terms of back-end infrastructure, since numerous users may request watching an AV live content substantially at the same time.
In view of such drawbacks of the HTTP-based streaming technologies for live AV content delivery, many operators rely on multicast-based live streaming technologies. It allows sizing the back-end infrastructure in a more cost-effective way, since numerous users attempting accessing the AV live content substantially at the same time results only in numerous requests for joining an already-setup multicast stream, which has a limited impact on the back-end infrastructure processing. Since live streaming is performed in such a multicast context and since most client devices require buffering a predefined quantity N of chunks before starting decoding the AV live content, joining an already-setup multicast stream results in a startup latency contradictory to a QoE (“Quality of Experience”) level that the CDN operators expect to provide to their users. In other words, the users would have to wait that buffers be filled in before being able to enjoy the AV live content. Buffering the predefined quantity N of chunks before starting decoding the AV live content allows compensating jitter and, when the client devices rely on unicast connections with an intermediary device converting the multicast data of the AV live content into unicast data, allows compensating potential retransmission occurring within the unicast connections. It should be noticed that relying on multicast transmission for AV live content doesn't allow the client devices to retrieve past chunks, since the AV content is live and cannot be watched on-demand.
Such a startup latency can be avoided by envisaging an hybrid version of the aforementioned technologies, namely downloading the first N chunks in a unicast way to fill in the buffers and join an already-setup multicast stream for the subsequent chunks. Such a process might be implemented in a gateway interconnecting a local network LAN (“Local Area Network”) to which the client device is connected and a backbone network WAN (“Wide Area Network”) via which the backend infrastructure provides the AV live content. However, the scalability issue related to the unicast way of requesting the first N chunks remains, which is thus still an issue for sizing the back-end infrastructure delivering the AV live content. For example, when a soccer game or another broadcast live event starts, numerous users would attempt accessing the AV live content substantially at the same time, which results in numerous substantially simultaneous unicast requests addressed to the back-end infrastructure.
The aforementioned startup latency issue is thus QoE-related. QoE aspects also concern error recovery when the device willing to receive the AV live content encounters an error when receiving a chunk of the AV live content. Whereas error recovery might be easily implemented in a unicast context with retransmission mechanism, such error recovery when an error is encountered when receiving a chunk of the AV live content is an issue in a multicast context.
It shall be noted that such issues arise in the more general context of AV live content delivery based, whether the bitrate of streams transporting the audio-visual contents be adaptive or fixed.
It is desirable to overcome the aforementioned drawbacks of the prior art. It is more particularly desirable to provide a solution that allows increasing QoE from the standpoint of a device willing to receive an AV live content.
It is in particular desirable to provide a solution that allows increasing QoE by reducing the aforementioned startup latency undergone by the device willing to receive the AV live content. It is also in particular desirable to provide a solution that allows increasing QoE by allowing error recovery when the device willing to receive the AV live content encounters an error when receiving a chunk of the AV live content.
It is further particularly desirable to provide a solution that overcomes the aforementioned scalability issue for sizing the back-end infrastructure intended to provide the AV live content. It is further particularly desirable to provide a solution that acts in a transparent manner for supporting legacy client devices.
It is also particularly desirable to provide a solution that operates in the context of adaptive streaming, thus allowing users to benefit from availability of different alternate versions of the AV live content encoded at various respective bit rates.
It is also particularly desirable to provide a solution that is simple and cost-effective.